Fixing timing issue with FileActivity's loading dialog show and dismiss #16145
Conversation
PhilLab
force-pushed
the
loading_dialog_timing_issue
branch
2 times, most recently
from
8e549a1 to
4dcbad8
Compare
PhilLab
changed the title
|
@alperozturk96 can you review? |
PhilLab
force-pushed
the
loading_dialog_timing_issue
branch
from
4dcbad8 to
407c1bd
Compare
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
alperozturk96
force-pushed
the
loading_dialog_timing_issue
branch
2 times, most recently
from
c285f15 to
cf9b180
Compare
alperozturk96
left a comment
alperozturk96
left a comment
There was a problem hiding this comment.
Hello
Thank you for the PR.
I got the following message when I ran the test:
at androidx.test.espresso.base.EspressoExceptionHandler.handleSafely(EspressoExceptionHandler.java:26)
at androidx.test.espresso.base.DefaultFailureHandler$TypedFailureHandler.handle(DefaultFailureHandler.java:158)
at androidx.test.espresso.base.DefaultFailureHandler.handle(DefaultFailureHandler.java:120)
at androidx.test.espresso.ViewInteraction.waitForAndHandleInteractionResults(ViewInteraction.java:385)
at androidx.test.espresso.ViewInteraction.check(ViewInteraction.java:366)
at com.nextcloud.client.FileDisplayActivityIT.testShowAndDismissLoadingDialog(FileDisplayActivityIT.kt:255)
and I saw the notification permission dialog, which overlaps with the loading dialog.
Maybe you can grant necessary permissions for FileDisplayActivity before running the test?
Thank you for the contribution.
|
@alperozturk96 Indeed. This should be fixed on a global level by the changes of #15424, which grabs the notification permission for all tests. If we merge that one first, the test here will also succeed. |
This timing issue was reproducible when testing RemoveFilesDialogFragment#removeFiles and sporadically "in the wild". However, no solution offered so far Signed-off-by: Philipp Hasper <[email protected]>
Before dismissing the dialog, we need to wait for a potentially pending transaction. As showing the dialog also includes the dismissing of prior instances, we need to wait there as well. Both is needed to satisfy the test case added in the previous commit. Otherwise, the dialog might be shown after it was meant to be dismissed already. This issue was observed when testing RemoveFilesDialogFragment's removeFiles() and also sporadically "in the wild". Signed-off-by: Philipp Hasper <[email protected]>
PhilLab
force-pushed
the
loading_dialog_timing_issue
branch
from
cf9b180 to
41f5502
Compare
…sion Before that, when starting individual tests from the command line or from inside the IDE, they could fail because a dialog asking for the permission to post notifications was blocking the view. While we are on it, added a small explanation to the other existing rule. Without that explanation it might be unclear why this is not also done via the same GrantPermissionRule used for the notifications. Signed-off-by: Philipp Hasper <[email protected]>
|
@alperozturk96 I cherry-picked the relevant commit from said PR, |
2 participants
Before dismissing the dialog, we need to wait for a potentially pending transaction. As showing the dialog also includes the dismissing of prior instances, we need to wait there as well.
Both is needed to satisfy the test case added in the previous commit.
Otherwise, the dialog might be shown after it was meant to be dismissed already. This issue was observed when testing RemoveFilesDialogFragment's removeFiles() and also sporadically "in the wild" when using the app productively
If you want to see for yourself, first checkout the test commit and see the test fail. Then checkout the fix commit and see the test succeed